REMARKS 

The above amendment and these remarks are in response 
to the Office action of 20 June 2003 by Examiner, Dr. 
Geoffrey R. Akers. 

Claims 12-19 are in the case, none having been allowed. 

35 U.S.C. 101 

Claim 15 has been rejected under 35 U.S.C. 101 for 
failing to provide a concrete and tangible result. 

Applicants have amended claim 15. 

The claim provides the concrete and tangible result of 
providing in a memory device a series of program steps 
executable by a computer for, among other things, 
automatically communicating a duplicate invoice rejection 
transaction back to a vendor for a duplicate invoice without 
posting the original electronic invoice to an accounts payable 
data base; and storing original electronic invoices not 
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identified as duplicate invoices into the accounts payable data 
base . 

The communicating of the rejection transaction and the 
storing of only non-duplicate invoices in the accounts 
payable data base are, applicants argue, concrete and 
tangible results. 

Applicants request that the rejection under 35 U.S.C, 
101 be reconsidered and withdrawn, and claim 15 allowed. 



35 U.S.C. 103 

Claims 12-13, and 15 have been rejected under 3 5 U.S.C. 
103(a) over Klein (U.S. 5,845,285) in view of Geer (U.S. 
5, 930, 778) . 

Applicants traverse . 

Neither Klein nor Geer, taken singularly or in the 
combination proposed by the Examiner, teach or suggest the 
invention as claimed . 
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Klein teaches a system and method for determining the 
accuracy of a database. He states: 

"The most precise way to determine the accuracy of a 
database is to review each and every field within each 
and every record in the database. However, in 
virtually every real-life situation the cost and time 
to review an entire database is prohibitive. Instead, 
a conventional technique is to request a professional 
trained in information audits to determine the accuracy 
of a database." (Klein, Col. 1, lines 48-55.) 

He then goes on to discuss other methods of the prior art 
and his own invention (utilizing neural networks) for 
identifying duplicate invoices, all of which are based on an 
examination of the accuracy of the overall database. 

With respect to claim 12, the Examiner appears to 
appreciate that distinction, for he observes "However, Klein 
does not specifically teach preprocessing of invoices." 
(Office Action, page 3, lines 6-7). Further, "Klein does 
not explicitly teach introduction to and rejection from a 
accounts payable data base." (Office Action, page 3, lines 
12-13) . 

Applicants agree. Nor does Klein teach such by 
implication, nor does Applicant claim rejection from an 
accounts payable database, for such assumes that the 
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invoices being checked are in the data base when they are 
checked and in applicants' invention duplicate invoices 
never make it into the accounts payable database. 

Applicants would add that Klein can only be considered 
as applicable to systems which examine the database, as 
distinguished from examining invoices for duplicates before 
they can be introduced into the data base. Klein clearly 
teaches a method of finding duplicates after data is entered 
into a database, and thus teaches away from applicants 
solution to the problem of duplicate invoice processing. 

The Examiner is correct in noting that "Klein does not 
explicitly teach grabbing an inbound EDI invoice file from a 
vendor before it is input to a accounts payable database and 
creating a transaction to a vendor." (Office Action, page 
4, lines 4-6) . The Examiner then takes official notice that 
"it is old and well known in the art of electronic 
communication and commerce to use EDI for invoicing." 
Applicants agree. 

However, the Examiner also asserts "However, official 
notice is taken that it is old and well known in the art of 
data entry to grab data before input into a database for the 
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purpose of examination for error." (Office Action, page 4, 
lines 6-8, Based on this assertion, the Examiner then 
concludes : 

"It would have been obvious to one of ordinary skill in 
the art at the time of applicants' invention to grab an 
inbound EDI invoice data before inputting it into a 
database because this would allow detection of 
duplicate as soon as possible." (Office Action, page 
4, lines 9-12) . 

Applicants traverse this conclusion. Because it is 
based in part on personal knowledge ("official notice"), 
Applicants request under 37 C.F.R. Section 1.107(b) an 
affidavit of the Examiner that provides citation in support 
of the above assertion at page 4, lines 6-8. 

The Examiner states that, "Klein does not explicitly 
teach creating transaction back to the vendor." (Office 
action, page 4, line 12). Applicants agree. Nor does Klein 
teach such by implication. The Examiner states: 

"However, Klein suggests this feature by disclosing a 
warning report system (column 26, particularly lines 
38-43)." (Office Action, page 4, lines 12-13). 

Applicants argue that the Klein reference does not teach 
creating a rejection message back to the vendor 
automatically . Referring to Klein Figure 24B and the 
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description of it at column 26, the electronic mail feed 
back is to data supplier (verification) on the output of 
approval system 158, and the warning system report 160 
output is for review of suspect data 162 and re -input of 
corrected data 164. Neither of these is related to invoice 
processing prior to loading the invoice to an accounts 
payable database, and both of them are related to the 
evaluation and processing of data already in that database. 
Applicants assert that nothing in Klein "suggests this 
feature" of creating transaction back to the vendor which 
rejects a duplicate invoipe before it is committed to the 
accounts payable database. 

The Examiner continues: 



"It would have been obvious to one of ordinary skill in 
the art at the time of applicants' invention to create 
a transaction back to the vendor because this would 
allow the vendor to be informed of the mistake and take 
corrective action." (Office Action, page 4, lines 14- 
16.) 



Applicants traverse this conclusion. Applicants are 
the first to recognize that duplicate invoices can be 
detected and rejected back to the vendor before being logged 
to the accounts payable database based upon a specific zero 
sum algorithm for identifying those duplicates. Previously, 
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any feed back to the vendor to "allow the vendor to be 
informed of the mistake and take corrective action" was done 
by analysis of the data logged to the A/P database. In this 
instance, the Examiner is engaging in improper hindsight 
reasoning, using applicants own teachings in derogation of 
the claim. 



The Examiner continues: 



"Klein does not explicitly teach determining duplicate 
invoice having same vendor invoice designation, same 
purchase order number, and same item number. However, 
Klein at least suggests this feature by disclosing 
determining duplicate invoice by comparing invoice 
number. Furthermore, official notice is taken that 
determining duplicate invoice having a same vendor 
invoice designation, same purchase order number, and 
same item number is old and well known in the art of 
invoice comparison. It would have been obvious to one 
or (sic) ordinary skill in the art at the time of 
applicant's invention to determine duplicate invoices 
by comparing same vendor invoice designation, same 
purchase order number and same item number because this 
would allow accurate identification of duplicate 
invoices." (Office Action, page 4, line 16 to page 5, 
line 4 . ) 



Again, applicants traverse. Any suggestion derived 
from Klein in this regard leads away from applicants 
invention. The Examiner seems to recognize (at page 5, 
lines 1-4) that analysis of invoices based on just purchase 
order number is not sufficient. To analyze incoming 
invoices before logging to the A/P database on invoice 
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number alone leads to a patently wrong conclusion. 
Applicants teach, and Klein does not teach, a specific zero 
sum calculation for determining duplicate invoices prior to 
logging the invoice to the A/P database -- in accordance 
with an algorithm which performs the calculations on vendor 
invoice number, purchase order number, and item number set 
forth in the claims. 

The above conclusion of the Examiner (Office Action, 
page 5, lines 1-4) is based upon official notice. 
Applicants request under 37 C.F.R. Section 1.107(b) an 
affidavit of the Examiner that provides citation in support 
of the assertion at page 4 line 19 to page 5, line 1 of the 
Office Action. 

With respect to claim 13, the Examiner asserts at page 
5, lines 5-6: 

"Klein discloses auditing step comprising sorting 
invoices against invoice number (column 6, particularly 
lines 8-10) . 

This is what Klein teaches: 

"An example of the conventional method of finding 
'duplicate data' is the way MIS departments typically 
deal with 'duplicate' invoices. Invoices that are from 
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the same company typically follow a certain pattern, 
such as 'ABClOO', 'ABClOl ' , etc. To find duplicate 
invoices a special program is created to search for 
invoices that match on the first several letters. This 
will produce a listing of all invoices that start with 
the same set of letters and vary on the remaining 
letters. A human then reviews the listing and 
determines which invoices are in fact 'duplicates' . 
The primary goal of this method is to find actual 
duplicates, i.e., invoices with the identical invoice 
number . " (Klein, col. 5, line 66 to col. 6, line 10). 

"This method of finding 'duplicate data' is basically 
useful in finding exact duplicates. However, it has 
been discovered that 'duplicate data' can be found in a 
system in a variety of forms that are not identical. 
FIGS. 17a-17e illustrate... various ways the same data 
can be entered into a system and still be considered 
duplicate data, i.e., data which has been entered two 
or more times identically or in varied form. FIG. 17a 
illustrates an example of original data. In addition 
to exact duplicates, the same data can be entered two 
or more times with any combination of the following 
types of variations: Misspelled Letters... Additional 
Letters... Missing Letters... Transposed Letters." 
(Klein, col. 6, lines 11-31.) 



It is clear from this that Klein is not teaching 
identifying duplicate invoices based on the zero sum 
algorithm of applicants. Rather, Klein teaches that the 
prior art method identifies duplicates as those with 
identical invoice number, and goes on to teach that his 
invention will identify duplicates where there has been 
input variations of misspelled, additional, missing, and 
transposed letters. This teaching, based as it is solely on 
invoice number, is so far from the specific zero sum 
algorithm of applicants' claim that reliance on it by the 
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Examiner goes contrary to well established principles: 

1. It is insufficient to establish obviousness that the 
separate elements of the invention existed in the prior 
art, absent some teaching or suggestion, in the prior 
art, to combine the elements. 

2. That a claimed invention may employ known principles 
does not itself establish that the invention would have 
been obvious, particularly where, as in the present 
case, those principles are employed to deal with 
different problems. The Examiner must consider the 
claim as a whole, and not piece together the claimed 
invention using the claims as a guide. 

3. The Federal Circuit has stated: " [o] ne cannot use 
hindsight reconstruction to pick and choose among 
isolated disclosures in the prior art to deprecate the 
claimed invention. [See In re Fritch, 23 USPQ 2d 1780, 
1784 (Fed. Cir . 1992) ] . 

The Examiner states : 

"Further Klein also discuss threshold value, term to 
describe the function of the 'net sum greater than 
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zero' of applicants' invention. It would have been 
obvious to one of ordinary skill in the art at the time 
of applicants' invention to use invoice for same 
vendor, purchase order billed, and items billed as 
entries that are used in neural network comparing and 
sorting method of Klein because those entry values are 
essential for determining duplicate data." [Office 
Action, page 5, lines 17-20.] 

Applicants traverse this assertion. Klein, for 
example, does not teach that same vendor, purchase order 
billed, and items billed can be used to derive a net zero 
sum. Rather, Klein teaches that the prior art method 
identifies duplicates as those with identical invoice 
number, and goes on to teach that his invention will 
identify duplicates where there has been input variations of 
misspelled, additional, missing, and transposed letters. 

Apparently, the Examiner is relying on personal 
knowledge in asserting that same vendor, purchase order 
billed, and items billed are "entry values . . . essential for 
determining duplicate data" [Office Action, page 5, lines 
19-20] , for Klein specifically teaches (as is quoted above, 
Klein Col. 6) other algorithms for determining duplicate 
invoices. Therefore, according to the specific teachings of 
Klein, there are other ways to determine duplicates. If 
there are other ways, then the Examiner must be relying on 
personal knowledge (or hindsight reconstruction of Klein in 
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view of Applicants' disclosure) in asserting otherwise. 
Consequently, applicants request the affidavit of the 
Examiner identifying specific art which supports the 
statement at lines 18-20 of the Office Action: "same vendor, 
purchase order billed, and items billed . . . entry values are 
essential for determining duplicate data." 

The Examiner states: 

"...obvious... to use zero as the threshold value 
disclosed in Klein because this would allow maximum 
detection of duplicates." [Office Action, page 5, line 
2 0 to page 6, line 2.] 

The only correspondence between zero sum as used in 
applicants' claims and "zero as the threshold value" in the 
Examiner's assertion is the use of the word "zero". Even if 
zero is used as the threshold value in Klein, it still does 
not teach the zero sum algorithm of applicants' claims. 
Klein teaches that his threshold value is set to identify 
fraudulent or duplicative data [Col. 27, line 36] present in 
a database being audited [Col. 27, line 5], and such data is 
described as "exact duplicates [or] the same data. . . entered 
two or more times with any combination of the following 
types of variations: Misspelled Letters... Additional 
Letters... Missing Letters... Transposed Letters...". 
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[Klein, col. 6, lines 11-31.] The Klein process for 
calculating accuracies and process error threshold is set 
forth at columns 21-30, all based on neural pattern matching 
techniques. There is no suggestion in Klein of the zero sum 
algorithm of applicants' claims. 

The Examiner states: 

"Klein also discloses a method for operating a 
computing system responsive to receipt of an electronic 
input (abstract)." [Office Action, page 6, lines 2-3.] 

What Klein teaches in the abstract is a data pattern 
build system which retrieves data from a database and 
generates pattern data from it. (Abstract, lines 7ff.) 
there is no teaching of operating a computing system 
responsive to receipt of an electronic invoice. The input 
in Klein is a request to conduct an audit on an already 
existing database, not the receipt of an invoice. What 
applicants claim is: 

. .preprocessing before introduction into an accounts 
payable data base original electronic invoices received from 
a vendor. . . [Claim 12, from which claim 13 depends.] 

Applicants are not merely claiming "operating a computing 
system responsive to receipt of an electronic input" , as the 
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Examiner seems to be suggesting. 



The Examiner continues: 



"Klein discloses automatically identifying previously 
received invoices having the same vendor invoice 
identifier (column 6, particularly lines 8-10, column 
16, lines 1-5). [Office Action, page 6, lines 3-5.] 



This is what Klein teaches: 



"To find duplicate invoices a special program is 
created to search for invoices that match on the first 
several letters. This will produce a listing of all 
invoices that start with the same set of letters and 
vary on the remaining letters. A human then reviews 
the listing and determines which invoices are in fact 
'duplicates'. The primary goal of this method is to 
find actual duplicates, i.e., invoices with the 
identical invoice numbers." [Klein, Col. 6, lines 3- 
10.] 

"In fact, all audits appear as simple audits to the 
latter user 116, as his or her role is limited to 
reviewing each sample field selected by the database 
auditor 100 and noting the number of errors in the 
field on an audit summary screen 1200. (This screen is 
shown if FIG. 12 and is described below in the section 
entitled 'Review of Sample Fields'.) The rest of the 
audit is managed automatically by the database auditor 
100." [Klein, Col. 15 line 65 to Col. 16, line 5.] 



How the second reference (Klein, Col. 16) relates to this 
issue is not apparent. With respect to the first (Klein, 
Col. 6), Klein teaches that duplicates are identified (in 
the prior art system Klein is here describing) by finding 
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duplicate invoice numbers. This does not teach determining 
duplicate invoices by the process outlined in applicants 
claims 12 and 13 which does not identify duplicates based 
on identity of invoice numbers but rather on the specific 
series of sorts and calculations set forth in the claims. 



The Examiner continues: 



''Klein does not explicitly teach automatically grabbing 
an invoice from a vendor before it is input to a 
accounts payable database and creating a transaction to 
a vendor. However, official notice is taken that it is 
old and well known in the art of data entry to grab 
data before input into a database for the purpose of 
examination for error. It would have been obvious to 
one of ordinary skill in the art at the time of 
applicants' invention to automatically grab an invoice 
data before inputting it into a database because this 
would allow detection of duplicate as soon as 
possible." [Office Action, page 6, lines 5-11.] 



Applicants traverse this conclusion. Because it is 
based in. part on personal knowledge ("official notice"), 
Applicants request under 37 C.F.R. Section 1.107(b) an 
affidavit of the Examiner that provides citation in support 
of the above assertion at page 6, lines 7-9. Further, the 
motivation for the conclusion (allow detection of duplicate 
as soon as possible) does not go to the reason for 
applicants process: which is to reject back duplicate 
invoices before they are introduced to the accounts payable 
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database. One of ordinary skill in the art at the time of 
applicants' invention could only conclude that Klein 
specifically teaches away from such, for Klein only 
considers examination of data which is obtained from or 
sampled from such a database. 



The Examiner continues: 



"Further, Klein does not explicitly teach automatically 
identifying invoices having corresponding items, and 
calculating the net sum of items on input invoice 
having corresponding items. However, Klein does 
discuss using neural network (column 27, particularly 
lines 54-65) that executes multiple comparing and 
sorting hits (column 28, particularly lines 28-41), and 
identifying data as duplicate if it does not pass a 
threshold number of hits (column 28, particularly lines 
44-45) . It would have been obvious to one of ordinary 
skill in the art at the time of applicants' invention 
to use item as a comparison factor in Klein's system 
because type of item is essential in determining 
duplicates." [Office Action, page 6, lines 11-18.] 



Applicants traverse. The Examiner is not correct in 
asserting that "type of item is essential in determining 
duplicates" . Klein itself teaches that his concept of 
duplicates is determined based on invoice number. Only 
applicants teach that 'type of item' is used in the specific 
zero sum calculation set forth in connection with a specific 
collection of sorts in claims 12-13. Certainly, assuming 
that Klein teaches 'multiple comparing and sorting hits' , 
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and even the concept of a 'threshold number of hits', does 
not and should not be interpreted as teaching, the specific 
sorts and zero sum calculation set forth in the claim. 
Applicants are not claiming 'number of hits', but rather 
zero sum based on specific 'hits' resulting from specific 
sorts . 

The Examiner continues: 

"Further, [i]t would have been obvious to one of 
ordinary skill in the art at the time of applicants' 
invention to calculat [e] the net sum of items to 
determine if the data is duplicate since this would 
utilize Klein's threshold value." [Office Action, page 
6, line 18 to page 7, line 1.] 

Applicants traverse. There is no correspondence 
between Klein's threshold value and applicants' net sum. As 
previously noted, even setting Klein's threshold value to 
zero does not identify an incoming invoice as a duplicate. 
Rather, Klein teaches that his threshold value is set to 
identify fraudulent or duplicative data [Col. 27, line 36] 
present in a database being audited [Col. 27, line 5], and 
such data is described as "exact duplicates [or] the same 
data. . . entered two or more times with any combination of 
the following types of variations: Misspelled Letters... 
Additional Letters... Missing Letters... Transposed 
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Letters...". [Klein, col. 6, lines 11-31.] No calculation 
of net sum is suggested by this teaching. The Klein process 
for calculating accuracies and process error threshold is 
set forth at columns 21-30, all based on neural pattern 
matching techniques. There is no suggestion in Klein of the 
zero sum algorithm of applicants' claims. 



The Examiner continues: 



"Klein does not explicitly teach automatically 
communicating a duplicate invoice message back to the 
vendor without posting the input invoice to the 
accounts payable database. However, Klein suggests 
this feature by disclosing a warning report system 
(column 26, particularly lines 38-43) . It would have 
been obvious to one of ordinary skill in the art at the 
time of applicants' invention to communicate a 
duplicate invoice rejection message back to the vendor 
because this would allow the vendor to be informed of 
the mistake and take corrective action." [Office 
Action, page 7, lines 1-7.] 



Applicants traverse. Klein specifically teaches that 
his processing is against the database, and that the notice 
of a possible duplicate record is via the warning report 
system 160 for manual or automatic review of suspect data 
and re-input of corrected data, and that the notice of 
approval via approval system 158 to data supplier (e.g., 
electronic mail). The Examiner's assertion to the contrary, 
that Klein suggests this feature of communicating a 
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duplicate invoice message back to the vendor without posting 
the input invoice is using applicants' disclosure against 
their own claims. That should not be permitted. 

The Examiner continues: 



"Further, it would have been obvious to one of ordinary 
skill in the art at the time of applicant's invention 
to refrain from posting the input invoice to the 
accounts payable database because this would prevent 
posting of duplicate entry Klein discloses posting to 
the system data determined not to be duplicate (column 
26, particularly lines 32-36). [Office Action, page 7, 
lines 7-10.] 



The Examiner is again using applicants' own disclosure 
against their claims. The Examiner cites no art describing 
or suggesting the feature of preventing the posting of 
duplicate invoices to the accounts payable database based on 
applicants' claimed zero sum analysis of incoming invoices. 

With respect to claim 15, the Examiner performs a 
reconstruction of applicants' claim and characterizes the 
teachings of Klein, as follows. Applicants annotate each 
statement after the preamble by setting forth the actual 
claim language, highlighted to show the claim limitations 
not taught by Klein. 
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Per Examiner: "As per claim 15, Klein discloses a 
program storage device readable by a machine, tangibly 
embodying a program of instructions executable by a 
machine to perform method steps for processing 
electronic input (abstract) , said method step 
comprising : 

Per Examiner, regarding claim 15: "automatically 
processing electronic invoices received from a vendor 
to identify duplicate invoices (abstract, column 5, 
particularly lines 55-65, column 6, particularly lines 
1-5, column 16, lines 1-5);" 

Applicants' claim 15 states [highlighted portions 
are not taught by Kline] : 

"... preprocessing before introduction into an 
accounts payable data base original electronic 
invoices received from a vendor to identify 
duplicate invoices, including: 

Klein is sampling invoice data already entered to a 
database, and not original electronic invoices received from 
a vendor. Throughout the specification, Klein speaks of 
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auditing an 



existing database, and not preprocessing invoice 



data before 



logging it to that database. 



'' identifying invoices having same vendor 
invoice designation, same purchase order 
number, and same item number; 

''calculating a net sum of items on invoices 
identified as having said same vendor invoice 
designation, said same purchase order number, 
and said same item number; 

"identifying as a duplicate invoice an 
original electronic invoice for which said 
net sum is greater than zero; , . 



Per examiner, regarding claim 15: "introducing data 
(invoices) not identified as duplicates into a system 
(column 26, particularly lines 32-36) ; and 
automatically rejecting data (invoices) identified as 
duplicates without introducing the data into the system 
(column 26, particularly lines 38-43, column 27, lines 
26-29)." [Office Action, page 7, lines 11-18,] 
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Applicants' claim 15 states: 



"... automatically communicatinQ a duplicate 
invoice rejection transaction back to said vendor 
for said original electronic invoice identified as 
a duplicate invoice without posting said original 
electronic invoice to said accounts payable data 
base ; and storing said original electronic 
invoices not identified as duplicate invoices into 
said accounts payable data base . " 



The Examiner states with respect to the preprocessing 
feature of applicants' claims: 



"Klein dos not explicitly teach preprocessing of 
invoices before introduction into an accounts payable 
data base. However, Geer discloses preprocessing of 
invoices before introduction into an accounts payable 
data base (abstract, column 6, particularly lines 43- 
45) . It would have been obvious. , . to use method of 
duplicate invoice identification of Klein in 
preprocessing of invoices of Geer because this would 
allow duplicate data to be sorted out as soon as 
possible." [Office Action, page 7, line 18 to page 8, 
line 4 . ] 



The teachings of Geer referenced by the Examiner are as 



follows : 



A system and process are described for effecting the 
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expedited submission into the payment system for 
collection of funds represented by financial 
instruments that are received by a payee at an item 
capture facility remote from the payee's depository 
bank in which the submission of the instruments into 
the payment system is coordinated with the payee's 
internal accounting process and the register of the 
deposit of the instruments with an account at the 
instruments payee's bank." [Geer, Abstract.] 

"...physical paper checks are not transported from the 
payee's location. Appropriate information from the 
checks is extracted and converted into electronic form 
for sorting, processing and transmission into and 
through the payment system. The physical checks are 
disposed of, typically following imaging and archival 
storage by electronic, optical, microfilm or other 
means at the payee's location (or other location remote 
from the depository bank) ." [Geer, col. 6, lines 40- 
49. ] 



Applicants traverse the Examiner's characterization of 
Geer. The preprocessing that Geer discloses occurs at the 
remote station, where the paper check is converted to 
electronic form "for sorting, processing and transmission 
into and through the payment system." There is no teaching 
or suggestion of pre-processing to identify duplicate 
invoices before they are transmitted into the payment 
system. 



The Examiner continues: 



"Klein does not explicitly teach introduction to and 
rejection from a accounts payable data base. However, 
Klein does suggest this feature by disclosing 
correction of the system (column 26, particularly lines 
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40-44) and filtering database (colunui 27, particularly 
lines 22-25) . Further, accounts payable data base is 
deemed to be inherent in Klein's description of 
invoicing system (column 5, particularly lines 46-65) . 
It would have been obvious... to introduce and reject 
data from an accounts payable database because this 
would allow filtering and sorting out to be implemented 
as soon as data is available." [Office Action, page 8, 
lines 4-11 . ] 



Applicants are not claiming " rejection from a accounts 
payable data base" , as distinguished from preventing posting 
to the data base. They are claiming: 



"automatically communicating a duplicate invoice 
rejection transaction back to said vendor. . . without 
posting said original electronic invoice to said 
accounts payable data base..." [Claim 15.] 

With respect to filtering, Klein teaches: 



"The analysis of the results are then presented in step 
22 8, and the user is prompted to determine whether the 
user would also like to manually filter database upon 
predetermined criteria in response to the results 
relating to the accuracy of the database." [Kline, 
col. 27, lines 20-24.] 



This reference from Kline about correcting a database 
and filtering database does not teach, cannot be construed 
to teach, that an original invoice is checked to determine 
if it is a duplicate invoice before it is loaded to the 
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accounts payable database. Rather, whatever filtering is 
done, is base on results relating to the accuracy of the 
database itself, and not applied against data before it is 
loaded to that database. 

"Klein does not explicitly teach determining duplicat 
invoice having same vendor invoice designation, same 
purchase order number, same item number, and havin[g] 
sum greater than zero. However, Klein at least 
suggests this feature by disclosing determining 
duplicate invoice by comparing invoice number." 
[Office Action, page 8, lines 11-14.] 

Applicants travers. The Examiner seems to recognize 
(at page 5, lines 1-4) that analysis of invoices based on 
just purchase order number is not sufficient. To analyze 
incoming invoices before logging to the A/P database on 
invoice number alone leads to a patently wrong conclusion. 
Applicants teach and claim, and Klein does not teach, a 
specific zero sum calculation for determining duplicate 
invoices prior to logging the invoice to the A/P database 
in accordance with an algorithm which performs the 
calculations not just on invoice number, as suggested by 
Kline, but on vendor invoice number, purchase order number 
and item number. 

The Examiner continues: 
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"Furthermore, official notice is taken that determining 
duplicate invoice having a same vendor invoice 
designation, same purchase order number, same item 
number, and having sum greater than zero is old and 
well known in the art of invoice comparison. It would 
have been obvious... to determine duplicate invoices by 
comparing same vendor invoice designation, same 
purchase order number, same item number, and having sum 
greater than zero because this would allow accurate 
identification of duplicate invoices. [Office Action, 
page 8, lines 14-20.] 



Applicants traverse. The Examiner is using applicants' 
own disclosure against their claim and drawing on official 
notice for which no specific reference has been supplied. 
Because it is based in part on personal knowledge ("official 
notice"), applicants request under 37 C.F.R. Section 
1.107(b) an affidavit of the Examiner that provides citation 
in support of the above assertion at page 8, lines 14-20. 
This will allow applicants to analyze the specific teachings 
upon which the Examiner relies, and enable them to prepare 
and submit explanatory affidavits in rebuttal. 



Claim 14 has been rejected under 35 U.S.C. 103(a) over 
Geer (U.S. Patent No. 5,93 0,778) and further in view of Rail 
(U.S. Patent No. 5,680,611). 



With respect to Geer, the Examiner states: 



"As per claim 14, Geer teaches a computing system 
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responsive to receipt of an electronic input invoice 
from vendors, comprising..." [Office Action, page 9 
lines 3-4,] 



Applicants traverse. Geer is not a system for 
processing electronic invoices from vendors. Rather, Geer 
teaches how to expedite the processing of checks received by 
a business with an accompanying payment form, to reduce the 
time from receipt of the check to the time the funds are 
available to the business to use (Col. 1, lines 18-24). 



The Examiner continues: 



''an accounts payable database (col 7 lines 4-25) (Fig 
1/4/5),..." [Office Action, page 9, lines 4-5,] 



Applicants traverse this characterization of Geer. 
This is what Geer teaches at the location cited by the 
Examiner : 



''In the present invention, the check payee 2 typically 
receives these check payments and associated statements 
through a functional component of the receiving 
organization known as remittance processing in retail 
organizations, or deposit processing when received by a 
bank. Item capture 4 in Fig, 1 represents these 
functions. Item capture 4 will typically occur at a 
location convenient to the payee's accounting functions 
5, Check receiving and item capture functions may be 
located at strategic bill collection points within a 
payee's service region. Most typically, the check 
receiving and item capture function of the payee will 
compare a payment stub with the enclosed check and send 
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the check on for further processing. The payment stub 
commonly received along with the check is processed 
further by the payee and the funds represented by the 
check are reconciled with the check drawer/payor ' s 
account. The stub may be stored in archival storage as 
paper, microfilm, etc., or otherwise used to account 
properly for the customer's payment. Payment stub 
processing and internal accounting procedures for the 
reporting and allocation of payments, are an adjunct of 
the funds collection system of the invention herein." 
[Geer, col. 7, lines 4-25.] 



There is no teaching here of invoice processing. Geer only 
discusses processing of check payments remittances or 
deposits. 



The Exami ne r cont i nue s : 



"sort logic for sorting invoices into credit/debit 

sequence in the order received (col 9 lines 26-28) (col 

9 lines 37-44) (Fig 1/14/12/16), ..." [Office Action, 
page 9, lines 5-6.] 



Claim 14 does not recite sort logic for sorting invoices 
into credit /debit sequence in the order received. Be that 
as it may be, Geer teaches: 



"The electronic check information as sorted, grouped 
and annotated 14 by the depository bank is sent via an 
appropriate communication link 15 into the payment 
system 12." [Geer, col. 9, lines 26-28.] 



"The payment system 12 receives checks from depository 
bank 10 and other banks of first and subsequent deposit 
(not depicted on Fig, 1) intended for various payor 
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banks, Bl, B2 , B3...Bn, collectively denoted as 16 in 
Fig. 1. The check information from the payment system 
12 reaches the appropriate payor banks 16 for proper 
debiting of the accounts of check writers 1 thus 
completing the payment cycle." [Geer, col. 9, lines 
37-45.] 



There is no suggestion here of sorting invoices into 
credit/debit sequence in the order received. Check 
information may be sorted, by any number of criteria, most 
likely by depositor account number and most likely not by 
debit /credit sequence in the order received. Even so, 
applicants' claim 14 does not recite the aspect of sorting 
into credit /debit sequence in the order received. 



With respect to Rail, the Examiner states: 



"Rail teaches net sum logic for evaluating debit 
invoices in sequential order with respect to previously 
received debit and credit invoices to identify a 
duplicate debit invoice item (Fig 
3/22 0/212/214/2 02/2 04/2 08) Fig 

2/104/106/108/114/116/110/112) (col 2 line 50-col 3 
line 5),..." [Office Action, page 9 lines 7-10.] 

"...a duplicate debit invoice item being an invoice 
item having a net sum greater than zero determined with 
respect to previously received invoices in the same 
vendor invoice designation, same purchase order number, 
and same item and posting logic being further operable 
for posting to said accounts payable database only 
those debit invoices for which said invoice itms [sic] 
have a net sum less than or equal to zero (col 4 lines 
46-63) (col 5 lines 39-49) (col 5 lines 8-22)." [Office 
Action, page 9, lines 10-15.] 
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Rail does not teach to one of ordinary skill in the art 
the rejection of invoices to vendors. Rail clearly teaches 
a method to review call records to prevent a record from 
appearing twice on a bill being sent to a customer. Its 
teachings clearly indicate that after matching the call 
records, if a duplicate is found, that the duplicate goes to 
an audit file, and is not rejected back to a vendor. 

Rail does not teach to one of ordinary skill in the art 
the use of net sum logic for evaluating invoices. Rail 
deals with the creation of bills to be sent for payment, not 
for invoices received for payment. Rail teaches a method 
that creates a "checksum" (specific characteristics of an 
invoice to be sent) and compares the checksum to checksum of 
previously created invoices to ensure a duplicate bill is 
not mailed. There is no teaching of how to prevent invoices 
to be paid from entering the database using a net zero 
logic. A 'checksum' is not a net zero calculation as that 
is set forth in applicants' claim. 

The Examiner concludes: 

"It would have been obvious... to combine Geer in view 
Rail to teach the above. The motivation for this is to 
describe a computing system that can correctly bill and 
remit debits and credits to clients and vendors." 
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[Office Action, page 9, lines 15-18.] 

Applicants are not claiming a system for "correctly 
billing and remitting debits and credits to clients and 
vendors." They are claiming a computing system including a 
preprocessor for identifying duplicate invoices before 
entering them into an accounts payable data base, and an 
invoice processor for communicating a duplicate invoice 
rejection back to the vendor. Neither Rail nor Geer teach 
such, either separately or in the combination suggested by 
the Examiner . 

Applicants urge that claim 14 be allowed over Geer in 
view of Rail , 
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SUMMARY AND CONCLUSION 



Applicants urge that the above amendments be entered 
and the case passed to issue with claims 12-19. 

If, in the opinion of the Examiner, a telephone 
conversation with applicant (s) attorney could possibly 
facilitate prosecution of the case, he may be reached at the 
number noted below. 



Date: 22 Sep 2003 

Shelley M Beckstrand, P.C. 
Attorney at Law 
314 Main Street 
Owego, NY 1382 7 

Phone: (607) 687-9913 

Fax: (607) 687-7848 



Sincerely, 



M. W, Beach, et al . 



By 
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